Advantages of a Layered Architecture

Conventional programming can sometimes make our code difficult to understand. This is why professionals are increasingly moving toward layered architecture. Before delving deeper into the details of clean architecture, let’s first discuss the advantages of layered architecture.

Loosely coupled#

The stages of the layered architecture are separated, and there is a great deal of data transformation between these stages. One way we can achieve independence—or loose coupling—between the components of a computer system is through the use of common data formats.

To better understand what loose coupling means for a programmer, let’s consider the last picture we saw in the previous section. What changes if the web framework was instead a command-line interface (CLI)?

What then changes if we have another type of data source—instead of a relational database—such as a set of text files?

As we can see in the images, both changes require the replacement of a component. After all, we need different codes to manage a command line instead of a web page. But the external shape of the system doesn’t change, and neither does the way data flows. This is because we created a system where the user interface (web framework, command-line interface) and the data source (relational database, text files) are details of the implementation and not core parts of it.

Testability#

The main advantage of a layered architecture is testability. When we separate components, we establish the data each component needs to receive and produce. This is so we can easily disconnect a single component and test it in isolation.

Let’s take the web framework component that we added and consider it in isolation for a moment. Ideally, we are able to connect a tester to its inputs and outputs, as we can see in the figure above.

Web layer testing#

Web layer testing is divided into the following four steps:

1. HTTP request
2. Method call
3. Method result
4. HTTP response

These steps play out in the following way.

1. The web framework receives an HTTP request with a specific target and a specific query string.
2. It then calls a method on the use case and passes specific parameters.
3. The use case returns our data.
4. The web framework converts this data into an HTTP response.

Since this is a test, we can use a simulated use case, that is, we can have an object that mimics what the use case does. This, in turn, doesn’t implement our business logic. We can then test if the web framework calls the method (Step 2) with the correct parameters. If it does, then the HTTP response will (Step 4) contain the correct data in the proper format. As we can see, all of this happens without involving any other part of the system.